Vieme, že tento hlavolam sa môže nachádzať v ľubovoľnom stave, ktorý patrí práve do jednej z dvoch navzájom disjunktných, rovnako veľkých množín stavov. Ľubovoľný stav vyjadrujú permutácie, takže počet možných stavov, patriacich do jednej z týchto množín je polovica z faktoriálu z M*N. Toto číslo neuveriteľne rýchlo rastie, takže nie je problém zahltiť pamäť počítača a dospieť k nepoužiteľne dlhým časom výpočtu. Nasledujúce príklady riešení (prvé tri) ukazujú, k akým časom sa je možné priblížiť pri aspoň trochu slušnej optimalizácii riešenia. Časy boli určené pre AMD Turion 1,4GHz, 500MB operačnej pamäti, priamo z IDE, pri náročnej hudbe na pozadí (asi 15% výkonu – to boli časy!).
Stavy z uvedených zoznamov je tiež vhodné využiť na testovanie vlastného riešenia. (Môžete skontrolovať, či môj algoritmus fungoval správne a neexistuje kratšia cesta medzi vybranými stavmi.) Tiež je možné využiť, že už viete, v akej najväčšej hĺbke môže byť cieľový uzol.
V prostredí NetBeans, v Jazyku JAVA 1.5, bol naprogramovaný algoritmus prehľadávania celého stavového priestoru do šírky. Oproti pôvodnému, všeobecnému postupu, bolo použitých niekoľko optimalizácií:
Výstupy pre rozmer:
6! = | 720 | |
8! = | 40 320 | |
9! = | 362 880 | |
10! = | 3 628 800 | |
12! = | 479 001 600 | |
12! = | 479 001 600 |
Rozmer 5*2 bol vytvorený takmer o 11 rokov neskôr, na notebooku s procesorom core i7 a 16GB pamäti. Desaťnásobný počet uzlov pre tento rozmer zvládol za približne rovnaký čas ako pôvodný notebook pre rozmer 3x3. Rozmer 4x3 je ale zatiaľ pre Javu priveľký. JVM je 32 bitový, zvláda heap do veľkosti 4GB, kde v pôvodnej verzii dokázal uložiť 12 miliónov uzlov a v novej verzii 25 miliónov uzlov. Rozmer 4x3 však obsahuje 240 miliónov uzlov. Na dosiahnutie hĺbky 29 už Java potrebovala asi tri minúty a viac ako polovicu z toho času bežal Garbage Collector.
Na riešenie hlavolamu s dvanástimi políčkami boli použité ďalšie optimalizácie: